Secure Configuration of Authentication Servers

ABSTRACT

Embodiments of the invention are directed to automatically populating a database of names and secrets in an authentication server by sending one or more lists of one or more names and secrets by a network management software to an authentication server. Furthermore, some embodiments provide that the lists being sent are encrypted and/or embedded in otherwise inconspicuous files.

FIELD OF THE INVENTION

This relates generally to authentication, and more particularly, tosecure and automatic configuration of an authentication server withdevice names and secrets.

BACKGROUND OF THE INVENTION

An authentication server is a server that provides authentication forvarious devices. For example, an authentication server may provideauthentication for devices on a network. Each device on the network maybe assigned a unique name that identifies that device on the network.For authentication purposes, each device may also be assigned a secret(such as a password). Each device may provide its name and secret inorder to authenticate itself (i.e., prove that it is in fact the deviceit purports to be). An authentication server may store the assignednames and secrets of the various devices and use them to determinewhether authentications taking place on the network are successful.Authentication servers are generally known in the art. For example, twoknown types of authentication servers are Remote Authentication Dial InUser Service (RADIUS) and DIAMETER servers. RADIUS and DIAMETER are alsonames of the protocols these servers follow. While RADIUS refers to“Dial In” it is no longer exclusively used for dial in networks and mayapply to other types of networks.

As noted above, an authentication server must have the correct name andsecret of a device it is to authenticate before it attempts toauthenticate it. In many types of networks (such as for example, storagearea networks or SANs) the authentication server is loaded with thesenames and secrets manually (e.g., by a user typing the names and secretsin an authentication server interface). This process can be timeconsuming, expensive, insecure and susceptible to user errors.

SUMMARY OF THE INVENTION

Embodiments of the invention are directed to automatically populating adatabase of names and secrets in an authentication server by sending oneor more lists of one or more names and secrets by a network managementsoftware to an authentication server. Furthermore, some embodimentsprovide that the lists being sent are encrypted and/or embedded inotherwise inconspicuous files.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an exemplary network according to embodiments ofthe present invention.

FIG. 2 is another diagram of an exemplary network according toembodiments of the present invention.

FIGS. 3A and 3B are a flowchart showing an exemplary method ofconfiguration of an authentication server according to embodiments ofthe present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description of preferred embodiments, reference is madeto the accompanying drawings which form a part hereof, and in which itis shown by way of illustration specific embodiments in which theinvention can be practiced. It is to be understood that otherembodiments can be used and structural changes can be made withoutdeparting from the scope of the embodiments of this invention.

Embodiments of the invention are directed to automatically populating adatabase of names and secrets in an authentication server by sending oneor more lists of one or more names and secrets by a network managementsoftware to an authentication server. Furthermore, some embodimentsprovide that the lists being sent are encrypted and/or embedded inotherwise inconspicuous files.

While the following description centers on Fibre Channel (FC) storagearea networks, embodiments to the present invention are not limited tothese networks. Accordingly, embodiments of the invention can be used inconjunction with other types of storage network such as, for example,iSCSI networks, Fibre Channel over Ethernet (FCoE), serial attached SCSI(SAS) networks, etc. Furthermore, embodiments of the present inventioncan be used with various non-SAN networks that may use similarauthentication mechanisms as the networks discussed above.

FIG. 1 is a diagram of an exemplary network according to someembodiments of the invention. Network 100 can be a SAN, such as an FC,iSCSI, or FCoE SAN, or another type of network. Network 100 can be acombination of two or more networks.

A plurality of nodes may be connected to network 100. These can includevarious types of computers or network enabled electronic devices suchas, for example, storage servers and/or redundant array of inexpensivedrives (RAID) controllers connected to a storage area network. The nodescan be configured to communicate with each other according to a protocolthat may require or allow authentication. For example, in the case of aFibre Channel network, the nodes can communicate through the FibreChannel protocol and use the DH CHAP protocol for authentication. In aniSCSI network, the CHAP protocol can be used for authentication. Eachnode of nodes 102-104 can store a name and secret associated with itselfand use it when authenticating itself to other nodes.

Authentication server 105 can be server used to assist nodes 102-104 inauthentication. Server 105 can be, for example, a RADIUS or a DIAMETERserver. It should be noted that RADIUS and DIAMETER are designations ofprotocols according to which server 105 can operate, and notdesignations of specific implementations. For example, there are severaldifferent types of RADIUS server software available today from differentvendors, such as the Internet Authentication Service provided byMicrosoft, Alepo Radius Server, FreeRADIUS, etc. The authenticationserver 105 can be a generally programmable computer executing anauthentication server software (such as one of the software productslisted above) or an application specific hardware appliance (such as,for example, the Infoblox RADIUSone). The authentication server may alsobe implemented at one of the network elements of network 100, such as,for example, as software running at a switch in network 100.

The authentication server may store the names and secrets of the nodesand verify authentications of the nodes. For example, if node 102 needsto authenticate node 103, it can send a challenge to node 103. Node 103can respond to the challenge with a message including its name and aresponse that is the results of cryptographic hash of the secret andother values including the challenge value back to node 102. (In somecases, the challenge can include a random number, and node 103 can usethe random number in building the response that is a cryptographic hashvalue (i.e. one way encryption) of the secret before sending it acrossthe network). Node 102 can then send node 103's name and secret to theauthentication server 105. The authentication server 105 can check thereceived name and secret of node 103 against respective values stored inits local database, and determine if there is a match. If there is amatch the authentication is successful. If there is no match, theauthentication has failed. The authentication server can send a messageback to node 102 indicating whether the authentication was successful.Based on this message, node 102 can determine whether node 103 is reallythe node it purports to be.

Thus, nodes 102-104 can authenticate each other without necessitatingthat each node store all the authentication data of all other nodes(which would make authentication very insecure). Therefore, nodes102-104 can be referred to as clients of authentication server 105 andcan include hardware or software that performs authentication clientfunctionality according to a relevant protocol (such as, for example,RADIUS or DIAMETER).

Computer 106 may also be connected to network 100. Computer 106 may runan authentication management application 107. Application 107 can be anapplication that manages the authentication of a set of networkconnected devices, such as nodes 102-104. The authentication managementapplication may also provide additional network managementfunctionalities and may be referred to as a network managementapplication. Alternatively, computer 106 can be an application specificappliance that is configured to perform the authentication managementfunction.

In some embodiments, the authentication management application 107 maybe implemented at one of the network elements of network 100, such as,for example, as software running at a switch in network 100. In someembodiments, the authentication management application may beimplemented at the authentication server 105, or may be executed at thesame computer as the authentication server.

The authentication management application may obtain the names of thenode it manages. It may perform this by using standard discoveryprotocols of network 100, or it may allow a user to enter the names ofthe nodes to be managed. Having obtained the names, the authenticationmanagement application can assign or otherwise establish secrets to thenodes it manages (i.e., nodes 102-104), and associate each secret withthe name of the node it is assigned to. After assigning or establishingthe secrets, the authentication management application may send to eachnode its assigned secret. The secrets may be encrypted duringtransmission. The authentication management application can assignsecrets automatically, by a predefined algorithm by the use of randomnumber generation or other key agreement protocols. Alternatively it mayallow a user of the application to enter the secrets. In someembodiments, nodes 102-104 can assign their own secrets and send theirsecrets to the authentication management application 107 through network100. The authentication management application may store the secretsassigned to devices 102-104 locally.

In some embodiments, the authentication management application may alsoperform a policy check of the assigned secrets. In some embodiments,there may exist rules for what types of secrets may be used. These rulesmay be used to prevent the assignment of “weak” secrets (i.e., secretsor passwords that are easy to compromise). Thus, the rules may specifythat the secrets must be of a predefined length, a predefinedcomplexity, that they must exclude dictionary words, etc. If a givensecret entered by a user or provided by a node fails the policy check,the authentication management application may refuse to assign thatsecret and may request the user or the node to provide another secret.

Once the authentication management application has assigned all secrets,it may assemble the secrets and the respective names of their associatednodes in a single data structure (such as, for example, a file) and sendthem to the authentication server. The authentication server can loadthe secrets and associated names in its local database and use them forauthentication of nodes 102-104 as discussed above. In order to send thefile of names and secrets to the authentication server, theauthentication management application may also include authenticationclient functionality (such as, for example, RADIUS or DIAMETER clientfunctionality).

The authentication management application may encrypt the file before itsends it to the authentication server. Alternatively, or in addition,the authentication management application may also use steganography toembed the file with names and secrets in another file. Steganography isa known technique of embedding a first set of data in a second set ofdata. Thus, the file with names and secrets can be embedded in a moreinauspicious looking file, such as a video or an audio file.Accordingly, steganography may be used to provide additional security bypreventing any rogue device that may be monitoring networkcommunications from flagging the transmitted file as important. Theauthentication server can extract the file with names and secrets fromthe other file and/or decrypt it.

The clients of authentication server (such as nodes 102-104 andauthentication management software 107) may be required to provide anauthentication server password to communicate with the authenticationserver. In some embodiments, that same password or derivation thereofmay be used to encrypt the file of secrets sent by the authenticationmanagement application 107 to the authentication server.

In some embodiments, the file including the list of names and secretscan be arranged in a predefined interoperable format. The format can bereferred to as interoperable because it may be readable and processableby different types of authentication servers offered by differentvendors.

In some embodiments, additional software 108 (such as, for example, oneor more scripts) may reside at the authentication server 105 or possiblyon the computer 106. The additional software 108 may be used to send orreceive or translate the file including the names and secrets of thenodes, perform any necessary decryptions and/or extraction and load thefile into a database for authentication server 105. Thus, additionalsoftware 108 may allow embodiments of the present invention to be usedwith various existing authentication server software products, withouthaving to further modify them for the purposes of the present invention.

Furthermore, different versions of additional software 108 may bedeveloped for different versions of existing authentication servers. Thedifferent versions may be configured to operate with a single format ofthe file comprising the names and secrets of the nodes which is to begenerated and sent by the authentication management application. Thus,embodiments of the present invention may provide for that a singleauthentication management application may be interoperable withdifferent types of authentication servers. In some embodiments, onceadded to the authentication server, the additional software 108 may beconsidered to be part of the authentication server or the authenticationmanagement application.

FIG. 2 is a diagram of another exemplary network according toembodiments of the present invention. More specifically, FIG. 2 is adiagram of a special case of the network of FIG. 1 involving a storagearea network. In FIG. 2, the generic network 100 of FIG. 1 actuallycomprises two connected networks—200 and 202. Network 200 can be astorage area network, such as, for example, an FC, iSCSI, FCoE and/orSAS networks. As noted above, nodes 102-104 can be various nodes thatmay connect to a SAN such as, for example, file servers, web servers,RAID arrays, etc.

Network 202 can be a local area network (LAN) or a wide area network(WAN). LAN/WAN 202 can be, for example, an Ethernet network. Gateway 201can be a device for interconnecting to different types of networks suchas SAN 200 and LAN/WAN 202.

As shown, nodes 102-104 as well as the computer 106 hosting theauthentication management application 107 can be connected to SAN 200.Thus, they may communicate with authentication server 105 throughgateway 201. In some embodiments, computer 106 may be alternativelyconnected to LAN/WAN 202. Alternatively, computer 106 may besimultaneously be connected to both networks 200 and 202.

As shown, authentication server 105 may be connected to network 202. Theembodiment of FIG. 2 may be beneficial because most existingauthentication servers are not configured for direct connection withmost existing SANs and instead require connection to an ordinaryEthernet network. Furthermore, some embodiments may provide thatauthentication server 105 serve multiple SANs connected to LAN/WAN 202.In some embodiments, multiple authentication servers can be present. Insome embodiments, a single authentication management application canserve multiple authentication servers.

As noted above, the combination of network 200, gateway 201 and network202 may be considered to be a single heterogeneous network.

FIGS. 3A and 3B are a flowchart showing an exemplary method ofconfiguration of an authentication server according to embodiments ofthe present invention. Referring to FIG. 3A, at step 300, theauthentication management application assigns secrets to various nodes.At step 302, the authentication management application performs a policycheck on the secrets. If one or more of the secrets fail the policycheck they may need to be reassigned (arrow 303). At step 304, theauthentication management application sends the assigned secrets totheir respective nodes. The secrets may be encrypted before being sentto the nodes. As noted above, other embodiments may provide that thenodes generate their own secrets and forward them to the authenticationmanagement application instead. Or in other embodiments, theauthentication management application may use a protocol to establishthe secret for a remote node.

At step 306, the authentication management application generates a datastructure including a list of the assigned secrets and the names of thedevices the respective secrets are associated with. As noted above, thedata structure may, but need not necessarily be a file. At step 308, thefile is encrypted and/or embedded in another file using steganography.At step 310, the file is sent to the authentication server.

Continuing to FIG. 3B, at step 312, the authentication server receivesthe file. At step 314, the authentication server decrypts and/orextracts the secrets and names from the received file and loads them inits local database. At step 316, configuration is complete. The nodesbeing served by the authentication server (e.g., nodes 102-104 of FIGS.1 and 2) may resume normal operation and the authentication server mayuse the stored names and secrets to perform authentication for thesenodes.

Thus, authentication can be performed without having to manually enternodes' names and secrets into an authentication server. This may greatlyimprove the ease of administration of a network. This may also improvethe security and reliability of a network, as manual entry of names andsecrets into an authentication server may be considered to be a securityvulnerability as well as a source of inadvertent entry errors.

Various devices discussed herein, such as authentication server 105,computer 106, and nodes 102-104 may run on programmable computers, orother types of programmable electronic devices. A programmable devicemay include a processor, such as a central processing unit (CPU) and amemory. The processor may operate by executing instructions stored inthe memory. These instructions may comprise, for example, theauthentication management application 107, one of various authenticationserver software products executing at authentication server 105, and/orscripts 108. The memory can also store data, such as the authenticationserver's local database, the file of node names and secrets, etc.

The various devices can also include networking hardware. The networkinghardware may include, for example, a network interface card (NIC—oftenused for connecting to Ethernet networks) and/or a host bus adapter(HBA—often used for connecting to FC or iSCSI networks). Some devicesmay include both a NIC and an HBA. For example, in the embodiment inwhich the computer 106 is connected to both SAN 200 and LAN/WAN 202,computer 106 may include a NIC for connecting to LAN/WAN 202 and an HBAand its associated driver software for connecting to SAN 200.

Although embodiments of this invention have been fully described withreference to the accompanying drawings, it is to be noted that variouschanges and modifications will become apparent to those skilled in theart. Such changes and modifications are to be understood as beingincluded within the scope of embodiments of this invention as defined bythe appended claims.

1. A method for configuring a management database comprising: assigninga plurality of secrets to a plurality of nodes of a network; generatinga data structure in each node of the plurality of nodes, the datastructure comprising the assigned secrets; securing the data structurein each node of the plurality of nodes using a password generatedaccording a key agreement protocol; and storing each generated passwordin the management database.
 2. The method of claim 1, further comprisingintegrating the data structure into an authentication server database.3. The method of claim 1, wherein securing the data structure comprisesencrypting the data structure.
 4. The method of claim 1, whereinencrypting the data structure comprises encrypting the data structurewith a password used for communications with the authentication serveror a derivation thereof.
 5. The method of claim 1, wherein securing thedata structure comprises embedding the data structure within a seconddata structure through the use of steganography.
 6. The method of claim1, further comprising generating the plurality of secrets.
 7. The methodof claim 1, wherein the assigning, generating, securing and storing areperformed by an authentication management application executed at acomputer that is distinct from an authentication server.
 8. The methodof claim 1, further comprising associating each secret with a uniquename of a node the secret is assigned to and saving the associated namesin the data structure.
 9. The method of claim 1, wherein the networkcomprises a storage area network.
 10. The method of claim 9, wherein thestorage area network is a network selected from the group consisting ofa Fibre Channel network, an iSCSI network and an FCoE network.
 11. Themethod of claim 1, further comprising: obtaining the assigned secretsfrom the data structure by an authentication server; and using theassigned secrets by the authentication server to perform authenticationfor the plurality of nodes. 12-15. (canceled)
 16. A device comprising aprocessor and a memory, the memory comprising a plurality ofinstructions executable at the processor and configured to cause theprocessor to: assign a plurality of secrets to a plurality of nodes of anetwork; generate a data structure in each node of the plurality ofnodes, the data structure comprising the assigned secrets; secure thedata structure in each node of the plurality of nodes using a passwordgenerated according a key agreement protocol; and store each generatedpassword in a management database.
 17. The device of claim 16, whereinthe instructions are further configured to cause the processor togenerate or otherwise establish the plurality of secrets.
 18. The deviceof claim 16, wherein the instructions are part of an authenticationmanagement application, and the device is distinct from anauthentication server.
 19. The device of claim 16, wherein theinstructions are further configured to cause the processor to associateeach secret with a unique name of a node the secret is assigned to andsave the associated names in the data structure.
 20. The device of claim16, wherein the network comprises a storage area network.
 21. The deviceof claim 20, wherein the storage area network is a network selected fromthe group consisting of a Fibre Channel network, an iSCSI network and anFCoE network. 22-25. (canceled)
 26. A network device comprising: amemory comprising a management database; and a hardware processoroperable to: generate a password according to a key agreement protocol;store the password in the management database; and assign a plurality ofsecrets to a network node, the plurality of secrets comprising thepassword, one or more of the plurality of secrets being stored in a datastructure in each node, the data structure being secured by thepassword.
 27. The network device of claim 26, wherein the data structureis encrypted by with the password.
 28. The network device of claim 26,wherein the data structure is embedded through the use of steganography.